the  application  and,  in  particular,  write  the  application  translator.  All  other  facilities 
are  provided  by  the  system. 

With  EC  as  the  main  tool  the  language  used  to  write  an  application  translator  is 
no  mystery:  it  is  EC  proper  plus  a  network  cluster  and  clusters  for  implementing  sets, 
sequences  and  tuples.  Since  the  input  usually  defines  nested  networks,  the  network 
- KA*«nU<rtr«l  rnni««  #vf  nMt#vl  networks  For 
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1.  Introduction 

CAD  software  systems  are  a  collection  of  programs  where  the  results  of  one  pro¬ 
gram  are  the  inputs  of  another.  These  programs  are  large,  complex  and  usually  CPU 
limited — often  written  independently  and  put  together  as  the  need  arises.  The  pro¬ 
grams  are  frequently  changed.  These  changes  may  be  due  to  changes  in  VLSI  technol¬ 
ogy,  but  often  they  are  also  a  result  of  the  continuing  evolution  of  the  CAD  algorithms 
themselves.  A  better  understanding  of  an  algorithm  often  leads  to  performance  im¬ 
provements  or  better  use  of  the  algorithm.  These  improvements  may  be  conceptually 
simple  while  their  effect  is  pervasive,  such  as  changing  a  datatype  from  a  list  to  a  2-D 
tree.  As  a  result,  a  satisfying  CAD  system  is  a  moving  target. 

A  frustrating  aspect  of  writing  new  systems  is  that  so  little  of  the  old  available 
programs  can  be  reused.  The  reason  is  that  it  takes  too  much  time  and  effort  to  find 
the  reusable  pieces  and  recast  them  for  the  new  use.  To  reuse  someone  else’s  software 
requires  understanding  the  details  of  his  or  her  program.  Sometimes  understanding 
these  unstructured  details  takes  more  effort  than  rewriting  the  program  again. 

We  believe  that  such  systems  should  be  design  for  reusability  by  anticipating 
change.  Our  thesis  is  that  this  goal  can  be  achieved  by  designing  the  software  by 
layers  of  problem  oriented  languages.  These  languages  are  implemented  by  suitably 
extending  a  “base”  language.2 

In  this  paper  we  illustrate  the  above  methodology  with  respect  to  VLSI  CAD 
programs  and  a  particular  language  layer:  a  language  for  handling  networks.  Networks 
made  of  components  and  their  interconnections  is  a  concept  shared  by  many  CAD 
programs.  We  capture  that  common  part  by  providing  a  language  for  handling  network 
problems.  Such  a  language  consists  of  our  “base”  language  (EC  or  Lisp)  plus  data 
types,  operations  and  control  structures  that  are  relevant  t'o  network  problems.  The 
network  language  is  but  one  of  several  languages  used;  other  languages  we  used  deal 

1  Currently  on  Sabbatical  at  the  Artificial  Intelligence  Laboratory  and  Department  of  EECS  at 
MIT,  Cambridge,  M A  02139 

2  Some  of  these  problems  cannot  be  eliminated  as  a  result  of  the  complexity  of  the  algorithms 
themselves. 
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with  sets,  two  dimensional  layout  structures,  waveforms,  etc.  The  discussion  of  the 
network  language  illustrates  this  technique. 

A  key  part  of  the  implementation  technique  is  that  the  base  language  is  extensi¬ 
ble.  We  solve  a  particular  set  of  problems  by  extending  the  base  language,  forming  a 
problem  oriented  language  for  the  particular  problem  at  hand  (for  example,  a  language 
for  manipulating  waveforms  or  the  network  language  discussed  below).  Of  particular 
importance  are  language  layers  that  capture  concepts  intrinsic  to  the  field.  Design 
based  on  such  layers  has  the  follow  advantages: 

(a)  The  programs  are  self  documenting  and  document  themselves  concisely.  The  bulk 
of  the  documentation  describes  the  problem  oriented  language  and  not  individual 
programs. 

(b)  Changes  involve  writing  a  new  algorithm  in  the  same  (problem  oriented)  language 
rather  than  writing  a  new  language.  This  automatically  ensures  that  new  programs 
use  parts  of  old  programs.  These  parts  are  the  concepts  encapsulated  in  the 
language. 

(c)  The  language  rarely  needs  to  be  adapted  to  changes,  only  the  application  (i.e. 
algorithm)  has  to  be  changed.  Occasionally,  the  language  may  also  need  to  be 
extended. 

We  base  our  conviction  in  the  power  of  the  language  approach  upon  the  progress 
made  in  other  fields  by  developing  languages  to  express  problems  and  their  solutions. 
For  example,  one  of  Newton’s  major  contribution  to  physics  was  the  development  of 
Calculus  which  can  be  viewed  as  a  collection  of  new  concepts  and  ways  of  putting  them 
together. 

The  changes  in  digital  design  field  over  the  last  two  decades  have  been  so  drastic 
that  one  wonders  how  the  field  maintained  its  unity.  We  claim  that  the  stability  of  the 
practitioners  language,  the  TTL  conventions,  is  the  source  of  this  unity.  In  spite  of  the 
technological  changes  the  language  adapted  remaining  relatively  constant,  maintaining 
communication  among  workers  in  the  field  and  preserving  the  field  unity. 

Consider  another  aspect  of  this  same  problem.  Most  conventional  design  method¬ 
ologies  begin  with  a  specification  of  the  system  to  be  built.  The  specification  should  be 
as  complete  and  as  accurate  as  possible.  Using  this  specification,  the  system  is  divided 
into  smaller  systems,  each  with  their  own  specification.  These  sub-systems  can  be 
attacked  independently  since  they  need  only  satisfy  their  specifications.  This  method¬ 
ology  is  generally  known  as  structured  design  and  is  widely  acclaimed  and  accepted. 

We,  however,  feel  that  this  methodology  is  inadequate  for  building  large  systems. 
The  key  flaw  in  structured  design  is  the  reliance  on  the  accuracy  of  the  specification.  For 
sufficiently  large  systems,  the  specification  is  always  incorrect.  At  the  beginning  of  the 
project,  the  project  itself  is  not  completely  understood  and  neither  are  its  components. 
During  the  project,  the  better  understanding  the  algorithms,  data  structures  and  their 
uses  leads  to  modifications  of  the  detailed  specifications.  At  the  of  the  project,  what 
was  built  may  meet  the  original  specification,  which  was  not  what  the  client  really  had 
wanted.  The  client  had  not  specified  what  he  had  thought  he  haul  specified. 


2 


How  can  we  deal  with  incorrect  and  ever  changing  specifications?  We  can  only 
assume  that  the  evolving  specification  is  not  far  wrong.  It  describes  a  family  of  systems 
near  the  desired  one.  We  suggest  building  a  platform  on  which  this  nearby  family 
of  systems  can  be  built  quickly.  This  platform  is  the  problem  oriented  language  we 
advocate.  This  language  simplifies  the  construction  of  the  specified  system,  and  when 
the  specification  is  modified,  it  is  straightforward  to  build  a  new  version  of  the  system. 
The  platform  itself  remains  constant  in  the  face  of  changes  in  the  specification,  since  it 
depends  upon  the  problem  domain  rather  than  a  specific  problem. 

At  this  point  an  historical  note  is  in  order.  In  the  LISP  community,  Joel  Moses 
was  the  first  to  suggest  that  layered  languages  would  be  an  effective  way  of  dealing 
with  design  in  the  face  of  change.  In  the  programming  language  community  the  related 
notions  are  “problem  oriented  languages”  and  “extensible  languages.”  The  practice  of 
problem  oriented  languages  leads  to  layers  of  languages.  Conversely,  the  implementa¬ 
tion  of  layers  of  languages  leads  uses  language  extensibility  in  order  to  build  problem 
oriented  languages. 

We  start  by  presenting  the  common  denominator  for  network  problems — the  lan¬ 
guage  for  handling  networks.  We  continue  by  presenting  two  different  implementations 
of  the  above  philosophy.  The  first  uses  UNIX  and  Enhanced  C  [8],  a  set  oriented  lan¬ 
guage  supporting  data  abstractions  based  on  C.  The  second  approach  uses  Common 
Lisp  on  a  LISP  machine  [13,  15].  In  each  case,  we  describe  the  basic  technique  and 
its  applications.  We  conclude  by  comparing  the  two  approaches.  The  two  authors  got 
together  to  write  this  article  when  they  discovered  their  goals  and  philosophy  were 
similar,  but  their  techniques  differ. 

The  body  of  the  paper  is  organized  as  follows.  Section  2  describes  a  general  network 
framework  for  CAD  that  both  the  EC+UNIX  and  the  LISP  approaches  share.  This 
is  the  fundamental  abstraction  used  in  this  paper.  In  Section  3,  we  discuss  how  EC 
can  be  used  to  implement  and  take  advantage  of  the  network  abstraction.  Section  4 
briefly  summarizes  the  different  approaches  used  by  LISP  for  the  same  problem.  The 
methodology  has  been  used  for  constructing  logic  simulators  [7],  VLSI  layout  system 
[17]  and  a  system  for  analyzing  linear  networks.  In  the  final  section  we  discuss  the 
practiced  experience  gained  by  using  the  methodology  and  we  also  compare  the  two 
approaches  taken. 

2.  Basic  Network  Model  and  Its  Language 

We  speak  about  entities  that  have  endpoints.  Networks  are  formed  by  identifying 
( connecting)  endpoints  of  entities.  An  entity  has  properties  that  contain  values.  One 
such  property  of  an  entity  is  its  type.  The  value  of  the  type  property  determines  the 
number  and  kind  of  the  other  properties  that  the  entity  has.  In  network  problems  we 
have  a  type  node  and  a  type  component.  A  node  has  a  single  endpoint  that  can  only 
be  connected  to  the  endpoints  of  components.  This  is  illustrated  in  figure  1.  Clearly, 
this  is  a  very  general  model — perhaps  more  general  than  required  for  networks.  We  are 
not  interested  in  minimal  models,  instead  we  show  that  the  major  network  constructs 
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Figure  1.  An  example  of  Nodes  and  Components 


can  be  built  simply  within  this  model. 

A  hierarchical  network  is  created  by  using  a  component,  C,  with  a  property  parent 
whose  value  is  a  network  rj.  The  nodes  of  t)  are  assigned  am  endpoint  property  that  is 
either  “empty”  or  refers  to  a  suitable  endpoint  of  C. 

A  homological  copy  of  a  network  is  an  important  and  useful  concept  [10].  A 
homological  copy  of  77  is  a  another  network  p  such  that  each  node  or  component  of  77  is 
associated  with  a  node  or  component  of  p  (possibly  a  many  to  one  relation).  Clearly 
that  association  is  a  property  of  p's  elements  and  p  can  be  manipulated  at  will  as  long 
as  77  remains  constant.  As  an  example  consider  the  schematics  that  a  designer  might 
use  to  describe  a  circuit.  The  schematics  have  more  spatial  detail  than  would  be  needed 
by  a  simulator  which  would  work  with  a  topological  equivalent  representation  of  the 
schematics.  This  topology  is  a  homological  copy  of  the  schematics.  This  concept  of 
homological  copies  is  similar  to  the  Sussman’s  Slices  [16]. 

Around  these  entities  we  construct  a  language  that  enables  us  to  handle  these 
entities.  The  language  allows  us  to  refer  to  and  change  their  properties;  perform  trans¬ 
formations  on  them  and  use  the  entities  in  more  complex  control  structures.  In  more 
technical  terms,  we  define  a  language  by  defining  constructors,  selectors,  various  other 
operations,  and  control  abstractions  that  are  appropriate  to  our  network  problems.  The 
following  examples  illustrate  both  the  language  and  its  use  for  writing  CAD  application 
programs. 

2.1  Displaying  a  Circuit 

Each  element  of  the  network  (both  nodes  and  components)  has  a  property,  say 
picture,  whose  value  is  (refers  to)  the  code  that  displays  the  element  picture  on  the 
screen.  In  addition,  there  is  a  coordinates  property  that  give  the  location  of  the 
element  on  the  screen.  The  following  loop  generates  a  picture  of  the  network: 


forall  elements  e  of  network  N  do 
display . element (e) 


display  checks  if  e. picture  is  nil;  if  so,  it  recurses  on  e’s  subcircuit. 
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display .element (element)  { 

if  (element. picture  **  nil) 

display -network (element . network) 

else 

element . picture (element . coordinates) 

} 

Obviously,  the  same  sort  of  operations  could  be  written  in  LISP.  Throughout  this 
paper  all  of  our  LISP  programs  are  written  in  Common  Lisp  [15].  We  would  begin  by 
writing  a  function  that  takes  two  arguments.  The  first  is  a  network  and  the  second  is 
a  functional  argument  that  is  applied  to  each  element  of  the  first  argument.  Call  this 
function  map-over-elements. 


(defun  display-network  (network) 

(map-over-elements  network 
(function  display-element))) 

The  display-network  function  displays  a  network  by  applying  the  function  display- 
element  to  each  element  of  network.  The  form  (function  display-network)  is  re¬ 
turns  the  function  associated  with  the  identifier  display-element.  This  extra  bit 
of  complexity  is  needed  became  Common  Lisp  allows  a  value  and  a  function  to  be 
associated  with  the  same  symbol. 


(defun  display-element  (element) 

(if  (null  (picture  element)) 

(display-network  (network  element)) 

(f uncall  (picture  element)  (coordinates  element)))) 

2.2  Simulation 

Consider  the  following  examples  of  simulation  programs:  synchronous  and  asyn¬ 
chronous  logic  simulation,  analog  simulation,  timing  simulation  [9],  etc.  Although  quite 
different,  these  programs  have  much  in  common.  Each  can  be  generated  by  programs 
that  traverse  the  networks,  using  the  properties  of  the  network  elements.  In  each  case 
the  handling  of  the  results  is  similar;  result  waveforms  have  to  be  associated  with  the 
network  elements  so  that  the  user  can  refer  to  them  as  properties  of  the  elements. 

For  each  kind  of  simulation  we  need  different  network  element  properties  and  a 
different  “generation  function” — the  function  that  generates  the  simulator  from  the 
network  description. 
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The  above  is  illustrated  by  an  example  of  a  simple  synchronous  logic  simulation. 
We  assume  that  the  behavior  of  each  component,  e,  is  a  finite  state  machine  described 

by 

5n-H  =  /e(^n»/n)i 

where  J*„  is  the  state  vector  at  time  n  and  I„  is  the  input  vector  at  time  n.  For  simplicity 
assume  that  s„  is  also  the  output  vector  at  time  n  and  that  inputs  to  all  components 
are  outputs  of  other  components.  ft  is  called  the  device  function. 

The  following  simple  program  generates  the  simulation  program. 

forall  elements  e  of  network  N  do  { 

gen(  state  and  next  state  variable  declarations  for  e)  ; 
gen("get_initial_conditions(e. state)"  )  ;  } 
gen  ("for  (t  •  t0  ;  t  <«  t  m4X  ;  t++)  {"); 
forall  elements  e  of  network  N  do  { 

gen  ("e.devicefun(e. inputs,  e. state,  e.next -state) ; "  )  ;  } 
gen  ("forall  elements  e  of  network  N  do  f 

e. state  *  e.next .state; 
store _results(e. state)  ;  }*'  ); 

gen  ("}"); 

The  following  LISP  fragment  implements  the  same  functionality  as  the  previous  EC 
one.  In  LISP  we  do  not  generate  a  program  but  we  run  directly  off  the  data  structure. 
Notice  also  that  we  do  not  generate  any  variable  declarations. 

(map-over-elements  A* 

(lambda  (e) 

(setf  (state  e)  (initial-conditions  e)))) 

(loop  for  t  *  to  below  t  mxx 

do  (map-over-elements  A* 

(lambda  (e) 

(push  (funcall  (devicefun  e)  (inputs  e)  (state  e)) 
(state-history  e))))) 

(loop  for  t  »  to  below  t  max 

do  (map-over-elements  N 
(lambda  (e) 

(setf  (state  e)  (first  (state-history  e)'))))) 

The  special  forms  begining  with  lambda  are  used  to  create  anonymous  functions. 
The  special  form  setf  is  used  to  perform  all  assignments  in  Common  Lisp.  The  state- 
history  slot  of  each  element  is  a  list  of  the  states  through  which  the  element  has  passed. 
The  first  component  of  state-history  corresponds  to  the  next-state  variable  used 
in  the  EC  program. 
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What  these  two  approaches  have  in  common  is  that  each  element  must  contain  its 
device  function,  information  about  its  state,  initial  conditions  and  connectivity.  The 
following  remarks  relate  to  these  two  versions  of  the  simulation  example. 

(a)  The  example  is  indeed  straight  forward.  Some  of  the  simplicity  is  a  result  of  this 
particular  simulation  method.  Under  the  conditions  stated,  the  order  of  the  calls 
to  the  device  function  in  the  time  loop  can  be  arbitrary. 

However,  we  believe  that  given  the  appropriate  network  language  the  “core”  of 
the  any  network  application  is  quite  simple.  That  is,  it  is  simple  compared  with 
the  layers  of  software  around  it — the  I/O  package,  the  handling  of  libraries,  the 
manipulation  of  results,  etc.  In  our  case,  these  facilities  are  provided  as  part  of 
the  software  environment.  They  are  provided  as  standard  interfaces  (driven  by 
sub- languages)  to  be  used  by  any  network  application.  The  internal  complexities 
of  these  facilities  are  the  user. 

( b)  The  EC  version  generates  a  program.  This  program  is  compiled  and  run  to  produce 
results.  The  Lisp  version  is  a  program  that  runs  to  produce  results.  The  techniques 
and  differences  between  the  two  approaches  are  elaborated  in  the  sequel. 

(c)  With  each  application,  different  information  is  associated  with  the  network  ele¬ 
ments. 

(d)  In  all  cases  the  computed  results  have  to  be  associated  with  the  original  network 
model  to  enable  communications  with  the  user. 

3.  Implementation  using  Enhanced  C  plus  UNIX 

The  design  of  Enhanced  C  (EC)  and  its  philosophy  are  described  in  [8].  EC  is  a 
set -oriented,  extensible,  C-like  language.  Extensibility  in  EC  involves  the  use  of  data 
abstractions  to  define  new  types.  EC’s  data  abstractions,  called  clusters,  are  macro-like 
devices  that  perform  substitutions  on  the  typed  syntax  tree.  EC’s  set  orientation  and 
data  abstractions  are  important  to  our  discussion.  We  shall  elaborate  on  these  topics 
before  describing  the  organization  of  the  CAD  system. 

A  set-oriented  language  is  a  language  containing  high  level  data  aggregates.  In  EC 
these  are  sets,  sequences,  tuples  and  “oneof's.”  The  semantics  of  sets  and  sequences 
are  as  in  mathematics.  As  programming  entities  they  may  be  thought  of  as  the  gen¬ 
eralization  of  the  array.  Tuples  and  oneofs  are  the  generalization  of  C’s  “structure" 
and  “union"  respectively.  With  these  data  aggregates  come  expressions  and  control 
statements  that  resemble  set  usage  in  mathematics;  for  example: 

Let  5  be  a  set  of  a  given  type,  and  x  an  object  the  same  type. 

add  x  to  5; 

exist  x  in  S  suchthat  <  predicate> 

forall  x  in  5  suchthat  <  predicate>  do  <  statement 

Set  orientation  helps  program  combinatorial  problems,  a  type  of  problems  common 
in  VLSI  CAD.  It  provides  a  concise  notation  that,  since  it  is  part  of  our  common 
education,  helps  in  both  programming  and  documentation. 
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Data  abstractions  are  means  of  declaring  new  types.  The  following  few  lines  of 
code  is  an  example  of  such  a  declaration. 

cluster  list  (T)  /*  EC  1  */ 

mode  T;  vhere  int  T;  /*  EC  2  */ 

{ 

/*  This  list  implements  a  sst  of  elements  of  type  T  storing  copiss  of 
elements  in  ths  list  */ 

rsp  type  listjt  *1;  /*  EC  3  */ 

typedef  struct  {  typs  list-st  *next; 

typs  T  member; 

}  liet-st; 

fun  int  doit( ,  }  /*  EC  4  */ 


opsr  void  opsr  forallCelment .llist ,st)  /*  EC  S  */ 

typs  T  slmsnt; 
typs  list  Hist; 
statsmsnt  st; 

{ 

typs  1  p; 

for(p*llist;  p!*(type  l)nil;  p*p->next) 

{  slmsnt  *  (p->msmbsr); 
st; 

} 

} 

proc  int  opsr  add( slmsnt , llist)  /*  EC  6  */ 

typs  T  slmsnt;  typs  list  llist; 

{ 

typs  1  p;  I*  dsclaration  •/ 

for  (p  *  (typs  1)  mallocCsizsof (typs  listjt)); 

p->member  «  slmsnt; 

p->nsxt  *  llist; 

llist  *p; 

result  1; 

} 


opsr  typs  list  opsr  +(...)  ...  {  ...  } 


/*  EC  7  +/ 


constant  typs  list  opsr  null( cluster .name) 
emods  cluster-name; 

{ 

(typ*  l)nil 

} 


/•  EC  0  */ 
/*  EC  9  •/ 


/•  and  clnttar  list  */ 

} 
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A  type  is  defined  by  its  representation  (EC  3) — the  data  structure  of  a  variable  of 
this  type;  and  by  a  set  of  operations.  Line  EC  4  defines  the  operation  forall  whose 
call  is  as  follows: 


forall  element  in  Hist  do  statement 
Line  EC  6  defines  the  operation  add,  which  may  be  used  in  the  following  manner: 


add  element  to  llist 

Line  EC  7  overloads  to  be  the  union  of  two  sets.  Line  EC  6  defines  a  constant, 
null,  the  empty  set. 

The  cluster  operations  are  selected  by  their  name  and  the  types  of  their  arguments 
(polymorphic  operations),  e.g.  “+”  may  denote  the  addition  of  integers,  the  union  of 
sets.  etc.  The  compiler  selects  the  appropriate  operation  among  those  built-in  and 
those  defined  by  the  user. 

The  EC  clusters  are  parameterized.  E.g.  T  on  line  EC  1  is  a  type;  this  cluster 
defines  a  set  of  T.  EC  cluster  operations  can  be  implemented  by  either  procedures  or 
macros.  The  former  case  is  illustrated  on  line  EC  6  (key  word  proc)  and  the  later  is 
illustrated  on  line  EC  5.  The  macros  perform  substitutions  on  the  typed  syntax  tree. 

Macro  implementations  of  cluster  operations  have  several  interesting  properties. 
They  avoid  the  procedure  call  overhead  and.  when  the  body  of  the  operation  is  small 
enough  they  produce  code  that  may  be  both  faster  and  smaller.  Since  binding  is 
done  at  compile  time  they  accept  both  statements  and  types  as  arguments  and  bind 
variables  “by  name.”  They  may  return  “lvalues”  and  appear  on  the  left  hand  side  of 
the  assignment  statement. 

The  following  sections  describe  the  general  structure  of  the  CAD  system  and  then 
dwell  on  the  language  aspects  that  are  central  to  our  discussion. 

3.1  System  Organization 

Figure  2  summarizes  the  system  organization  as  a  set  of  data  structures  with  the 
transformations  from  one  data  structure  to  another.  The  transformations  are  repre¬ 
sented  as  arrows. 

The  input  is  described  by  an  input  language.  The  components  are  described  by 
giving  a  (possibly  parameterized)  type  and  a  name.  For  example, 


AND(WIRE(2) )  al,  a2; 

describes  a]  and  a 2  as  two  components  of  type  AND(Wire(2)).  Wire(2)  is  a  type  and 
is  used  as  a  parameter  of  type  AND.  A  component’s  connections  are  described  by  stating 
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Input  Procastor 


which  endpoints  are  connected  to  which  component’s  input  endpoint.  Although  this 
example  does  not  show  it,  the  input  usually  describes  nested  networks,  i.e.,  components 
are  defined  by  means  of  networks. 

The  input  language  is  processed  by  a  program  that  we  call  the  input  processor. 
When  that  program  encounters  a  type  it  searches  the  database  for  an  appropriate  type 
description  described  below. 

The  database  is  arranged  as  Unix  files  and  directories.  A  directory  is  devoted  to 
each  type  (the  types  directory).  Each  such  directory  contains  a  file  describing  the  com¬ 
ponent  topology,  i.e.  names  of  endpoints,  nature  of  endpoints  (input,  output,  tri-state). 
For  each  application  the  type  directory  contains  a  file  describing  the  component's  prop¬ 
erties.  e.g.  power  and  size,  and  a  file  containing  the  cluster  describing  the  behavior  of 
the  type  for  each  application. 

The  input  processor  uses  the  topology  file  for  checking  for  input  consistency  and 
builds  a  general  network  data  structure  describing  the  network  (the  network  data  struc¬ 
ture  in  figure  2).  Each  element  is  described  by  an  object  (tuple)  whose  properties 
(components)  are  the  basic  characteristics  of  the  elements  (name,  endpoints)  and  the 
application  properties  read  from  the  application  file. 

The  application  translator  is  a  program  that  runs  on  the  general  data  structure  and 
produces  the  applicationprogram ,  The  application  program  is  then  translated  by  the 
EC  compiler  into  runnable  code,  using  data  abstractions  called  from  the  database.  The 
object  code  is  run  on  the  input  to  produce  results.  The  (new)  results  are  manipulated 
by  a  waveform  program  to  produce  other  results  that  the  user  can  view,  print,  or 
otherwise  inspect. 

For  introducing  a  new  application  the  user  must  provide  the  database  entries  for 
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the  application  and,  in  particular,  write  the  application  translator.  All  other  facilities 
are  provided  by  the  system. 

With  EC  as  the  main  tool  the  language  used  to  write  an  application  translator  is 
no  mystery:  it  is  EC  proper  plus  a  network  cluster  and  clusters  for  implementing  sets, 
sequences  and  tuples.  Since  the  input  usually  defines  nested  networks,  the  network 
cluster  contains  operations  that  produce  homological  copies  of  nested  networks.  For 
sets,  sequences,  etc.  the  programmer  uses  the  language  facilities  provided  by  EC  and 
clusters  he  either  extracts  from  the  standard  library  or  writes  himself.  The  network 
cluster  requires  some  additional  elaboration. 

Our  network  elements  have  two  kinds  of  properties: 

•  properties  that  are  application  independent  and  are  used  to  capture  the  nature 
for  the  elements  as  part  of  a  network,  e.g.  connectivity.  We  call  these  properties 
network  generic  properties. 

•  Properties  that  are  application  dependent,  e.g.  the  device  function  in  the  simula¬ 
tion  application. 

We  would  like  to  generate  one  cluster  whose  representation  and  operations  include 
the  generic  operations  and  the  application  oriented  properties.  This  is  an  “inheri¬ 
tance"  mechanism — the  new  cluster  inherits  the  properties  of  the  network  cluster  and 
a  (pseudo)  cluster  whose  operations  are  the  application  dependent  operations. 

At  this  time.  EC  does  not  have  automatic  inheritance  [4,  3,  14]  and  this  particular 
inheritance  is  done  in  the  way  described  below. 

(1)  The  input  processor  generates  the  network  data  structure  as  a  fixed  part  per 
component  with  a  “hook”  for  application  dependent  properties.  Each  application 
dependent  entry  carries  its  name,  its  type  and  its  value. 

( 2 1  The  cluster  that  contains  the  generic  network  operation  is  augmented  by  operations 
that  access  the  application  properties.  These  operations  are  picked  up  from  the 
database  and  inserted  ( “include”  style)  into  the  network  cluster. 

4.  Use  of  Lisp  Machines  for  CAD 

Schema  was  developed  using  Common  Lisp  on  a  Lisp  machine.  LISP  is  extremely 
well  suited  for  building  new  languages.  Several  of  the  features  of  LISP  contribute 
this  property.  Significant  power  is  achieved  through  the  use  of  data  abstraction  (as 
embodied  by  flavors  [4],  which  includes  inheritance).  The  free  variables  of  procedures 
and  functions  can  be  closed  over  to  create  closures.  These  closures  are  first  class  citizens 
and  can  be  passed  to  and  from  other  functions  and  stored  in  data  structures.  Finally, 
its  uniform  syntax  (lack  of  it)  simplifies  the  creation  of  semantic  extensions.  The  use 
of  macros  allows  these  extensions  to  be  incorporated  smoothly. 

At  least  two  integrated  VLSI  CAD  systems  have  been  built  on  Lisp  machines. 
Schema  [6]  is  being  developed  at  MIT  with  the  help  and  collaboration  of  colleagues  at 
Harris,  Corp.,  and  NS  [5]  which  was  developed  at  Symbolics,  Inc.  These  two  systems 
share  a  common  heritage  from  the  Daedalus  system  developed  at  MIT  [2]  and  many 
key  ideas. 
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SCHEMA  was  developed  to  handle  all  of  the  aspects  of  designing  VLSI  circuits. 
Thus  it  contains  tools  for  schematic  entry,  layout  and  simulation.  Furthermore,  it 
is  built  upon  a  large  body  of  tools  that  can  be  used  to  build  additional  CAD  tools. 
Because  the  entire  design  and  all  of  the  tools  reside  in  a  single  address  space  a  somewhat 
different  approach  needs  to  be  taken  than  is  used  in  a  Unix  environment.  And  yet, 
there  are  still  strong  similarities  with  the  approach  used  in  EC.  The  following  diagram 
corresponds  to  figure  2  used  to  describe  the  EC  organization. 


Figure  3.  CAD  tools  using  Schema 


As  with  EC,  the  core  of  the  design  system  is  the  network  description  language.  In 
SCHEMA  this  language  is  interpreted  as  a  procedure  for  generating  a  memory  resident 
data  structure  that  describes  the  topology  of  a  circuit.  In  Figure  3  this  is  the  “Input 
Description.”  This  language  may  make  use  of  definitions  of  other  circuits  from  a  library, 
thus  allowing  the  hierarchical  description  of  circuit. 

The  data  structure  that  results  is  not  totally  passive.  Code  can  be  attached  to 
components  and  nodes  in  the  data  structure.  (This  is  the  main  use  of  objected  oriented 
programming  in  SCHEMA.)  Some  of  the  code  is  included  in  the  input  description  while 
other  code  is  added  by  application  programs.  Thus  a  simulator  might  add  code  to 
model  the  voltage  and  current  constraints  of  a  particular  device. 

The  hierarchical  network  data  structure  is  not  optimal  for  simulation  purposes. 
For  certain  types  of  simulations  it  contains  too  much  detail  (logical  simulators  are  not 
concerned  with  the  construction  of  an  AND  gate)  while  for  other  simulation  types 
the  hierarchical  structure  gets  in  the  way.  To  deal  with  both  of  these  problems  a 
homological  copy  is  built  which  has  the  optimal  structure  for  the  application  program. 
Schema  provides  mechanisms  for  building  and  operating  on  the  homological  copies, 
which  are  extensions  of  the  network  description  language. 
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In  SCHEMA  both  the  network  data  structure  and  its  homological  copies  reside  in 
memory  simultaneously.  The  user  tends  to  deal  with  the  network  data  structure  and 
is  often  not  aware  of  the  homological  copy.  To  ease  the  use  of  the  system,  links  are 
preserved  between  the  homological  copy  and  the  network  data  structure.  This  allows 
questions  about  the  result  of  simulations  to  be  directed  through  the  network  data 
structure  to  the  homological  copies. 

Perhaps  the  feature  of  the  Lisp  Machine  environment  that  distinguishes  it  the 
most  from  Unix-like  environments  is  that  all  the  design  tools,  as  well  as  the  design 
itself,  reside  in  a  common  address  space.  This  characteristic  makes  it  especially  easy 
for  disparate  CAD  tools  to  communicate  through  shared  data  structures.  For  instance, 
a  schematic  editor  and  a  simulator  are  able  to  examine  and  modify  a  common  data 
structure  that  represents  a  topology  thus  simplifying  both  the  user  interface  to  the 
simulator  and  the  creation  of  incremental  analysis  tools.  Far  less  programmer  time 
is  spent  flattening  data  structures  into  text  files  and  reparsing  them  for  use  in  differ¬ 
ent  tools.  The  “language”  in  which  the  CAD  tools  are  built  can  include  higher  level 
primitives  than  text  files.  Furthermore,  the  co-residence  of  the  different  tools  allows 
one  CAD  tool  to  invoke  another  when  information  is  lacking.  Thus  a  circuit  simulator 
could  invoke  the  layout  program  to  inquire  about  the  capacitances  of  different  nodes. 
This  approach  allows  the  tools  to  interact  as  collection  of  cooperating  experts  rather 
than  a  sequence  of  files  transducers. 

The  major  disadvantage  of  this  approach  is  that  modifications  and  annotations  to 
data  structures  persist  until  the  next  time  the  workstation  is  rebooted.  This  means 
that  modifications  to  data  structures  must  either  ue  able  to  be  undone  when  necessary 
or  are  permanent. 


5.  Practice  and  Experience 

Two  applications  were  built  with  EC  rising  this  philosophy.  The  first  is  a  simulator 
for  logic  networks  [7]  that  makes  extensive  use  of  the  network  layer  mentioned  earlier. 
The  second  system  does  automatic  layout  in  a  fashion  similar  to  PI  [17,  12].  The  same 
network  language  layer  was  used  to  create  nested  networks,  while  most  of  the  layout 
algorithms  were  built  on  another  layer  consisting  of  EC,  sets  and  sequences.  This 
system  is  intended  as  a  testbed  for  a  variety  of  different  algorithms.  The  use  of  layered 
languages  made  the  expressions  of  the  algorithms  concise,  readable  and  easy  to  modify. 

The  network  language  layer  of  SCHEMA  was  used  to  build  a  variety  of  different 
simulators  and  as  an  interface  to  conventional  circuit  simulators  like  Spice  [11].  In 
fact  a  very  large  number  of  languages  layers  were  used  in  SCHEMA.  Among  them  were 
layers  for  graphic  imaging,  for  building  user  interfaces,  for  editing  graphical  structures, 
for  dealing  with  permanent  version  of  the  data  structures  in  SCHEMA,  for  manipulating 
symbolic  mathematical  expressions,  etc.  In  each  case,  less  experienced  programmers 
were  able  to  construct  rather  sophisticated  applications  using  the  linguistic  tools  pro¬ 
vided. 
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6.  Summary  and  Conclusions 

The  two  systems  share  a  common  philosophy:  To  construct  a  CAD  tool,  first 
define  a  language  that  captures  the  concepts  common  to  the  field  and  widely  accepted 
by  workers  in  the  field.  Next,  build  the  CAD  tool  using  this  language.  For  example, 
consider  building  a  logic  simulator.  This  simulator  is  an  example  of  a  class  of  programs 
that  manipulate  networks.  We  begin  with  a  network  language,  and  then  extend  it 
to  one  that  is  appropriate  for  constructing  simulators.  The  logic  simulator  is  written 
in  the  simulation  language.  Notice  that  we  build  in  “extra”  generality.  The  network 
language  can  be  used  for  problems  other  than  simulation.  The  simulation  language  can 
be  used  for  either  logic  simulation  or  circuit  simulation. 

This  philosophy  is  implemented  in  a  similar  fashion  in  both  systems.  In  both 
cases,  the  system  is  built  on  a  base  language,  EC  and  LISP  respectively,  with  addition 
problem  specific  languages  constructed  by  extending  the  base  languages.  In  EC  this 
is  done  using  clusters,  where  the  macro  oriented  operations  are  used  for  implementing 
control  abstractions.  In  LISP  this  is  done  using  flavors  to  implement  data  abstraction; 
the  control  abstractions  are  implemented  using  macros  and  functional  arguments. 

The  differences  between  these  two  systems  revolve  around  two  points:  the  large 
address  space  used  by  Lisp  and  the  early  binding  by  compilation  used  by  EC.  The 
Lisp  machine  world  uses  a  very  large  address  space  allowing  many  tools  and  their  data 
structures  to  co-exist,  while  the  Unix/EC  world  places  each  tool  in  its  own  address 
space  and  shares  data  through  the  file  system.  The  Unix/EC  world  tends  to  bind  early 
have  the  compiler  make  as  many  decisions  as  possible,  while  the  Lisp  world  delays  those 
decisions  until  run  time. 

The  large  address  space  allows  SCHEMA  to  rely  on  “in  core”  data  structures  rather 
than  using  files.  This  allows  CAD  tools  to  share  common  data  structures  and  to 
communicate  simply  by  passing  pointers  to  these  data  structures.  This  environment 
allows  the  tools  to  appear  as  an  single  program.  This  eliminates  the  need  to  translate  to 
and  from  characters  to  the  data  structures  used  by  the  CAD  tools.  Furthermore,  CAD 
tools  are  now  able  to  invoke  other  CAD  tools  more  easily  in  this  common  environment. 

The  SCHEMA  tools  include  the  schematic  entry  system,  the  layout  editor,  simulator 
and  others.  These  tools  share  common  network  data  structures,  but  often  have  slightly 
different  structures  for  their  own  use.  These  tools  and  their  data  structures  all  co-exist 
in  the  same  large  address  space. 

The  early  binding  by  compilation  used  by  EC  has  advantages  and  disadvantages. 
The  disadvantages  are  that  the  communication  between  the  results  and  the  original 
specification  of  the  network  has  to  be  done  via  files  and  dictionaries,  which  complicates 
the  CAD  system.  And  if  the  application  requires  iteration  across  the  boundaries  be¬ 
tween  CAD  tools  that  application  becomes  quite  expensive.  The  advantage  of  early 
binding  by  compilation  is  the  gain  in  run-time  performance  for  CPU  bounded  problems. 

The  comparison  between  run-time  performance  of  conventional  machines  running 
compiled  EC  and  the  Lisp  machine  running  Lisp  is  not  simple.  We  do  not  have  signifi¬ 
cant  tests  that  run  in  both  environments.  The  Lisp  system  attains  speed  improvements 
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by  special  hardware  and  by  compilation.  We  don’t  feel  that  there  is  any  reason  why 
this  method  is  should  be  inherently  slower  or  faster  than  a  conventional  environment. 

Currently  a  Lisp  machine  system  is  a  relatively  expensive  item.  The  Unix  system 
runs  on  conventional  machines. 
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